From: [email-masked]
Date: Mon, 30 Aug 93 13:05:59 +0100

I tried to formulate some flow examples from ISO 10026 with CPI-C and tx.
This results in some ideas concerning the 2 interfaces.
How do you think about it?

Examples for CPI-C 2.0 with OSI TP Functional Unit Commit
=========================================================

  CPI-C and tx                                  CPI-C   OSI-TP
  calls                                         state   Service
						changes
A) Chained Transactions

a) ISO 10026-3 C.2.2 Provider supported chained transactions

  Superior:

  tx_begin
  tx_set_transaction_control TX_CHAINED
  Initialize_Conversation                       1->2
  Set_Sync_Level CM_SYNC_POINT
  Set_Transaction_Control CM_CHAINED_TRANSACT    
  Allocate                                      2->3    TP-BEGIN-DIA-rq
  Send_Data                                             TP-DATA-rq
  Receive                                               TP-GRANT-CTL-rq
  |data_received=CM_COMPLETE_DATA_RECEIVED      3->4    TP-DATA-in
  |status_received=CM_SEND_RECEIVED             4->3    TP-GRANT-CTL-in
  tx_commit                                             TP-COMMIT-rq
  |                                                     TP-COMMIT-in
  |                                                     TP-DONE-rq
  |=TX_OK                                               TP-COMMIT-COMP-in

  Send_Data                                             TP-DATA-rq
  Receive                                               TP-GRANT-CTL-rq
  |data_received=CM_COMPLETE_DATA_RECEIVED      3->4    TP-DATA-in
  |status_received=CM_SEND_RECEIVED             4->3    TP-GRANT-CTL-in
  Deallocate                                    3->10   TP-DEF-END-DIA-rq
  tx_commit                                             TP-COMMIT-rq
  |                                                     TP-COMMIT-in
  |                                                     TP-DONE-rq
  |=TX_NO_BEGIN                                 10->1   TP-COMMIT-COMP-in

  It seems to be more user-friendly if we make the following changes   
  to CPI-C (Table 3 on page 26):

    If Initialize_Conversation is called after tx_begin
    the default value of sync_level is CM_SYNC_POINT.
    If Initialize_Conversation is called after tx_begin
    the default value of transaction_control is equal to the
    transaction_control characteristic of TX.

  Table 32 on page 306 describes that the Functional_Units parameter
  of TP-BEGIN-DIALOGUE-indication is mapped to the sync_level and
  transaction_control characteristics. But there is no CPI-C call
  Extract_Transaction_Control. Table 32 should describe that
  Functional_Units is mapped to the CPI-C characteristic sync_level
  and the TX characteristic transaction control.

  Subordinate:

  Accept_Conversation                           1->4    TP-BEGIN-DIA-in
  Extract_Sync_Level CM_SYNC_POINT
  tx_info transaction_control=TX_CHAINED
  tx_begin
  Receive CM_COMPLETE_DATA_RECEIVED                     TP-DATA-in
  |status_received=CM_SEND_RECEIVED             4->3    TP-GRANT-CTL-in
  Send_Data                                             TP-DATA-rq
  Receive                                               TP-GRANT-CTL-rq
  |status_received=CM_TAKE_COMMIT               3->11   TP-PREPARE-in
  tx_commit                                             TP-COMMIT-rq
  |                                                     TP-COMMIT-in
  |                                                     TP-DONE-rq
  |=TX_OK                                       11->4   TP-COMMIT-COMP-in

  Receive CM_COMPLETE_DATA_RECEIVED                     TP-DATA-in
  |status_received=CM_SEND_RECEIVED             4->3    TP-GRANT-CTL-in
  Send_Data                                             TP-DATA-rq
  Receive                                               TP-GRANT-CTL-rq
  |                                                     TP-DEF-END-DIA-in
  |status_received=CM_TAKE_COMMIT_DEALLOCATE    3->13   TP-PREPARE-in
  tx_commit                                             TP-COMMIT-rq
  |                                                     TP-COMMIT-in
  |                                                     TP-DONE-rq
  |=TX_NO_BEGIN                                 13->1   TP-COMMIT-COMP-in
 
  The tx_begin call at the subordinate is only needed to satisfy
  TX state tables. It would be a better solution to change TX in the
  following way:
  tx_begin can be omitted if the sync_level of the received conversation
  startup request is equal to CM_SYNC_POINT or CM_SYNC_POINT_NO_CONFIRM.

b) ISO 10026-3 C.3.6.1 TP-ROLLBACK request issued during the active phase

  Superior:

  tx_begin
  tx_set_transaction_control TX_CHAINED
  Initialize_Conversation                       1->2
  Set_Sync_Level CM_SYNC_POINT
  Set_Transaction_Control CM_CHAINED_TRANSACT    
  Allocate                                      2->3    TP-BEGIN-DIA-rq
  Deallocate                                    3->10   TP-DEF-END-DIA-rq
  tx_rollback                                           TP-ROLLBACK-rq
  |                                                     TP-DONE-rq
  |=TX_OK                                       10->3   TP-ROLLBACK-COMP-in

  I do not understand the reason why we need a CPI-C call Deferred_Deallocate.
  Chapter 4.14 describes that the Deferred_Deallocate call does not need to
  be the last call on the conversation but Deallocate must be the last call
  on the conversation.
  On the other side chapter 4.13 describes that Deallocate with
  deallocate_type=CM_DEALLOCATE_SYNC_LEVEL and sync_level=CM_SYNC_POINT
  performs the same function as Deferred_Deallocate. Also the state
  tables in appendix C describe that the conversation in the above
  example goes back to state 3.

  Subordinate:

  Accept_Conversation                           1->4    TP-BEGIN-DIA-in
  Extract_Sync_Level CM_SYNC_POINT
  tx_info transaction_control=TX_CHAINED
  tx_begin
  Receive CM_TAKE_BACKOUT                       4->4    TP-ROLLBACK-in
  tx_rollback                                           TP-DONE-rq
  |=TX_OK                                       4->4    TP-ROLLBACK-COMP-in

c) ISO 10026-3 C.3.6.2 TP-ROLLBACK request issued after a TP-PREPARE indication

  Superior:

  tx_begin
  tx_set_transaction_control TX_CHAINED
  Initialize_Conversation                       1->2
  Set_Sync_Level CM_SYNC_POINT
  Set_Transaction_Control CM_CHAINED_TRANSACT    
  Allocate                                      2->3    TP-BEGIN-DIA-rq
  Deallocate                                    3->10   TP-DEF-END-DIA-rq
  tx_commit                                             TP-COMMIT-rq
  |                                                     TP-ROLLBACK-in
  |                                                     TP-DONE-rq
  |=TX_ROLLBACK                                 10->3   TP-ROLLBACK-COMP-in

  Subordinate:

  Accept_Conversation                           1->4    TP-BEGIN-DIA-in
  Extract_Sync_Level CM_SYNC_POINT
  tx_info transaction_control=TX_CHAINED
  tx_begin
  Receive                                               TP-DEF-END-DIA-in
  |status_received=CM_TAKE_COMMIT_DEALLOCATE    4->13   TP-PREPARE-in
  tx_rollback                                           TP-ROLLBACK-rq
  |                                                     TP-DONE-rq
  |=TX_OK                                       13->4   TP-ROLLBACK-COMP-in

  No problems.

d) ISO 10026-3 C.6.1 The commiting phase driven by TP-COMMIT          

			A
		  +-----^-----+
		  B           C
			      |
			      D

  Superior A:  

  tx_commit                                             TP-COMMIT-rq
  |                                                     TP-COMMIT-in
  |                                                     TP-DONE-rq
  |=TX_OK                                               TP-COMMIT-COMP-in

  Subordinate B:

  Receive status_received=CM_TAKE_COMMIT                TP-PREPARE-in
  tx_commit                                             TP-COMMIT-rq
  |                                                     TP-COMMIT-in
  |                                                     TP-DONE-rq
  |=TX_OK                                               TP-COMMIT-COMP-in

  Intermediate C:

  Receive status_received=CM_TAKE_COMMIT                TP-PREPARE-in
  tx_commit                                             TP-COMMIT-rq
  |                                                     TP-COMMIT-in
  |                                                     TP-DONE-rq
  |=TX_OK                                               TP-COMMIT-COMP-in

  Subordinate D: 

  Receive status_received=CM_TAKE_COMMIT                TP-PREPARE-in
  tx_commit                                             TP-COMMIT-rq
  |                                                     TP-COMMIT-in
  |                                                     TP-DONE-rq
  |=TX_OK                                               TP-COMMIT-COMP-in

  No problems.

e) ISO 10026-3 C.7.2 Rollback from a subordinate during the active phase      

			A
		  +-----^-----+
		  B           C
			  +---^---+
			  D       E

  Superior A:  

  ... (Send state) ...
  Prepare (->C)                                 3->15   TP-PREPARE-rq
  Receive CM_TAKE_BACKOUT (<-C)                 15->?   TP-ROLLBACK-in
  tx_rollback                                           TP-DONE-rq
  |=TX_OK                                       ?->3    TP-ROLLBACK-COMP-in

  The CPI-C state table on page 283 describes that returncode
  CM_TAKE_BACKOUT cannot occur in state 15. This may be wrong.

  Subordinates B, D, E:

  Receive CM_TAKE_BACKOUT                       4->4    TP-ROLLBACK-in
  tx_rollback                                           TP-DONE-rq
  |=TX_OK                                       4->4    TP-ROLLBACK-COMP-in

  Intermediate C:

  Receive status_received=CM_TAKE_COMMIT (<-A)  4->11   TP-PREPARE-in
  tx_rollback                                           TP-ROLLBACK-rq
  |                                                     TP-DONE-rq
  |=TX_OK                                       11->4   TP-ROLLBACK-COMP-in

B) Unchained Transactions

a) ISO 10026-3 C.2.3 Provider supported unchained transactions

  Superior:

  tx_begin
  tx_set_transaction_control TX_UNCHAINED
  Initialize_Conversation                       1->2
  Set_Sync_Level CM_SYNC_POINT
  Set_Transaction_Control CM_UNCHAINED_TRANSACT    
  Set_Begin_Transaction CM_BEGIN_IMPLICIT
  Allocate                                      2->3    TP-BEGIN-DIA-rq(BT=t)
  Send_Data                                             TP-DATA-rq
  Receive                                               TP-GRANT-CTL-rq
  |data_received=CM_COMPLETE_DATA_RECEIVED      3->4    TP-DATA-in
  |status_received=CM_SEND_RECEIVED             4->3    TP-GRANT-CTL-in
  tx_commit                                             TP-COMMIT-rq
  |                                                     TP-COMMIT-in
  |                                                     TP-DONE-rq
  |=TX_OK                                               TP-COMMIT-COMP-in

  tx_begin                                              TP-BEGIN-TA-rq
  Send_Data                                             TP-DATA-rq
  Receive                                               TP-GRANT-CTL-rq
  |data_received=CM_COMPLETE_DATA_RECEIVED      3->4    TP-DATA-in
  |status_received=CM_SEND_RECEIVED             4->3    TP-GRANT-CTL-in
  tx_commit                                             TP-COMMIT-rq
  |                                                     TP-COMMIT-in
  |                                                     TP-DONE-rq
  |=TX_OK                                               TP-COMMIT-COMP-in
  Deallocate                                    3->1?   TP-END-DIA-rq

  According to table 17 on page 297 the only CPI-C call mapping to
  TP-BEGIN-TRANSACTION-request is Include_Partner_In_Transaction.
  Does tx_begin also map to TP-BEGIN-TRANSACTION-request? The P2P
  document describes this mapping. The CPI-C should do this also.

  The CPI-C state table (table 13 on page 281) describes that Deallocate
  with deallocate_type=CM_DEALLOCATE_SYNC_LEVEL and sync_level=CM_SYNC_POINT
  leads from state 3 to state 10. This is not ok for unchained transactions.
  With unchained transactions Deallocate with deallocate_type=
  CM_DEALLOCATE_SYNC_LEVEL and sync_level=CM_SYNC_POINT must be handled
  as sync_level=CM_NONE if the dialogue is not in transaction mode.

  Subordinate:

  Accept_Conversation                           1->4    TP-BEGIN-DIA-in(BT=t)
  Extract_Sync_Level CM_SYNC_POINT
  tx_info=1 (i.e. transaction mode)
  |transaction_control=TX_UNCHAINED
  tx_begin
  Receive CM_COMPLETE_DATA_RECEIVED                     TP-DATA-in
  |status_received=CM_SEND_RECEIVED             4->3    TP-GRANT-CTL-in
  Send_Data                                             TP-DATA-rq
  Receive                                               TP-GRANT-CTL-rq
  |status_received=CM_TAKE_COMMIT               3->11   TP-PREPARE-in
  tx_commit                                             TP-COMMIT-rq
  |                                                     TP-COMMIT-in
  |                                                     TP-DONE-rq
  |=TX_OK                                       11->4   TP-COMMIT-COMP-in
  tx_info=0 (i.e. not in transaction mode)

  Receive status_received=CM_JOIN_TRANSACTION   4->4?   TP-BEGIN-TA-in
  tx_begin
  Receive CM_COMPLETE_DATA_RECEIVED                     TP-DATA-in
  |status_received=CM_SEND_RECEIVED             4->3    TP-GRANT-CTL-in
  Send_Data                                             TP-DATA-rq
  Receive                                               TP-GRANT-CTL-rq
  |status_received=CM_TAKE_COMMIT               3->11   TP-PREPARE-in
  tx_commit                                             TP-COMMIT-rq
  |                                                     TP-COMMIT-in
  |                                                     TP-DONE-rq
  |=TX_OK                                       11->4   TP-COMMIT-COMP-in
  tx_info=0 (i.e. not in transaction mode)
  Receive CM_DEALLOCATED_NORMAL                 4->1    TP-END-DIA-in

  The CPI-C state table (table 13 on page 283) describes that
  status_received=CM_JOIN_TRANSACTION cannot occur in any states.
  This may be wrong.

b) ISO 10026-3 C.6.2 The commiting phase with TP-PREPARE and TP-READY

			A
		  +-----^-----+
		  B           C
			      |
			      D

  Superior A:  

  ... (Send state and transaction mode) ...
  Prepare (->C)                                 3->15   TP-PREPARE-rq
  Receive status_received=CM_PREPARE_OK (<-C)   15->15  TP-READY-in
  tx_commit                                             TP-COMMIT-rq
  |                                                     TP-COMMIT-in
  |                                                     TP-DONE-rq
  |=TX_OK                                       15->3   TP-COMMIT-COMP-in

  According to description of the CPI-C call Prepare (page 148)
  it should be possible to get information about the action of the
  subordinate by calling Receive. And according to the description
  of Receive (page 155) status_received=CM_PREPARE_OK seems to be
  this information.
  But Appendix D.2.3 (page 306) describes that TP-READY-in is handled
  by the resource recovery component. Table 31 on page 306 may be wrong.

  On page 287 in table 15 the state numbers for Prepared state and
  Initialize_Incoming state have to be exchanged.
  The same state table describes that tx_commit=TX_OK leads from state
  Prepared to state 4. I think this is wrong. The final state has to be
  state 3.

  Subordinates B, D:

  ... (Receive state and transaction mode) ...
  Receive status_received=CM_TAKE_COMMIT        4->11   TP-PREPARE-in
  tx_commit                                             TP-COMMIT-rq
  |                                                     TP-COMMIT-in
  |                                                     TP-DONE-rq
  |=TX_OK                                       11->4   TP-COMMIT-COMP-in

  Intermediate C:

  ... (transaction mode) ...
  ... (Conversation to A in Receive state) ...
  ... (Conversation to D in Send    state) ...
  Receive status_received=CM_TAKE_COMMIT (<-A)  4->11   TP-PREPARE-in
  Prepare (->D)                                 3->15   TP-PREPARE-rq
  tx_commit                                             TP-COMMIT-rq
  |                                                     TP-COMMIT-in
  |                                                     TP-DONE-rq
  |=TX_OK                                       11->4   TP-COMMIT-COMP-in
						15->3

c) ISO 10026-3 C.7.1 Rollback from the root during the active phase

			A
		  +-----^-----+
		  B           C
			      |
			      D

  Superior A:  

  ... (Send state and transaction mode) ...
  tx_rollback                                           TP-ROLLBACK-rq
  |                                                     TP-DONE-rq
  |=TX_OK                                       3->3    TP-ROLLBACK-COMP-in

  Nodes B, C, D:

  Receive CM_TAKE_BACKOUT (<-superior)          4->4    TP-ROLLBACK-in
  tx_rollback                                           TP-DONE-rq
  |=TX_OK                                       4->4    TP-ROLLBACK-COMP-in

  No problems.

d) ISO 10026-3 C.7.2 Rollback from a subordinate during the active phase
   (modified for Polarized Control)

  Superior A:  

  ... (Send state and transaction mode) ...
  Send_Data (->C)                                       TP-DATA-rq
  Receive (<-C)                                         TP-GRANT-CTL-rq
  |CM_TAKE_BACKOUT                              3->4    TP-ROLLBACK-in
  tx_rollback                                           TP-DONE-rq
  |=TX_OK                                       4->3    TP-ROLLBACK-COMP-in

  Subordinates B, D, E:

  Receive CM_TAKE_BACKOUT                       4->4    TP-ROLLBACK-in
  tx_rollback                                           TP-DONE-rq
  |=TX_OK                                       4->4    TP-ROLLBACK-COMP-in

  Intermediate C:

  Receive data_received=CM_COMPLETE_DATA_RCVD           TP-DATA-in
  |status_received=CM_SEND_RECEIVED                     TP-GRANT-CTL-in
  tx_rollback                                           TP-ROLLBACK-rq
  |                                                     TP-DONE-rq
  |=TX_OK                                       4->4    TP-ROLLBACK-COMP-in

e) self made example

			A
			|
			B
			|
			C

  Suppose there exist dialogues A-B and B-C with chained transactions
  and not in transaction mode.

  Superior A:

  tx_begin                                              TP-BEGIN-TA-rq
  Send_Data                                             TP-DATA-rq
  Receive                                               TP-GRANT-CTL-rq
  |data_received=CM_COMPLETE_DATA_RECEIVED      3->4    TP-DATA-in
  |status_received=CM_SEND_RECEIVED             4->3    TP-GRANT-CTL-in
  tx_commit                                             TP-COMMIT-rq
  |                                                     TP-COMMIT-in
  |                                                     TP-DONE-rq
  |=TX_OK                                               TP-COMMIT-COMP-in

  Intermediate B:

  Receive status_received=CM_JOIN_TRANSACTION           TP-BEGIN-TA-in
	(<-A)                                   4->4
  tx_begin
  Receive CM_COMPLETE_DATA_RECEIVED                     TP-DATA-in
  |status_received=CM_SEND_RECEIVED             4->3    TP-GRANT-CTL-in
  Send_Data                                             TP-DATA-rq
  Receive                                               TP-GRANT-CTL-rq
  |status_received=CM_TAKE_COMMIT               3->11   TP-PREPARE-in
  tx_commit                                             TP-COMMIT-rq
  |                                                     TP-COMMIT-in
  |                                                     TP-DONE-rq
  |=TX_OK                                       11->4   TP-COMMIT-COMP-in

  According to example B.a) tx_begin results in a TP-BEGIN-TRANSACTION-request
  to the subordinate. If tx_begin is needed to accept the CM_JOIN_TRANSACTION
  from the superior, there are no means to accept the transaction from
  the superior and not to open a transaction with the subordinate.
  So this example is another reason to change TX as described in example
  Aa).

-----------------------------------------------------------------------------
Peter Binninger                     Tel.:  07531-87-4758
Computer Gesellschaft Konstanz      Fax:   07531-87-4888
Postfach 100154                     Email: [email-masked]
78401 Konstanz
Germany